Skip to content

PBR Materials#75

Open
tychedelia wants to merge 4 commits intoprocessing:mainfrom
tychedelia:materials-pbr
Open

PBR Materials#75
tychedelia wants to merge 4 commits intoprocessing:mainfrom
tychedelia:materials-pbr

Conversation

@tychedelia
Copy link
Member

Adds support for PBR materials based on Bevy's StandardMaterial.

At a high level, our material API is going to operate on named fields: mat.set("foo", 1.0). This is the intended API for custom materials and largely mirrors how Processing4 handles its Shader type. Because StandardMaterial is a built in, in this PR we handle it as a special case where we map field names to setting properties on the StandardMaterial asset struct. But, from the perspective of the user, we want a pbr material to basically feel like any other material, just one whose shader you don't control.

Some more specific notes:

  • We support both "immediate" and "retained" materials. Immediate materials will allow the user to change the pbr properties of their current batch/rendering context. Retained materials are an entity that can be used to set the "current" material for following geometry draws. We may want to change this and have the geometry draw just also accept a material param.
  • We may want to think more about how this interacts with 2d. In theory, these methods only make sense in 3d, but in practice there's nothing wrong with users setting these, they just will look weird unless they use lights, which will also look weird in ortho perspective.
  • The batching logic has gotten a bit more tricky.

@tychedelia tychedelia requested a review from catilac February 18, 2026 20:12
Copy link
Contributor

@catilac catilac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left questions and comments. i know there are updates coming from our offline discussion. really great :)

value: &MaterialValue,
) -> Result<()> {
match name {
"base_color" | "color" => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why use &str instead of enum?

Comment on lines +56 to +74
pub fn set_property(
In((entity, name, value)): In<(Entity, String, MaterialValue)>,
material_handles: Query<&UntypedMaterial>,
mut standard_materials: ResMut<Assets<StandardMaterial>>,
) -> Result<()> {
let untyped = material_handles
.get(entity)
.map_err(|_| ProcessingError::MaterialNotFound)?;
let handle = untyped
.0
.clone()
.try_typed::<StandardMaterial>()
.map_err(|_| ProcessingError::MaterialNotFound)?;
let standard = standard_materials
.get_mut(&handle)
.ok_or(ProcessingError::MaterialNotFound)?;
pbr::set_property(standard, &name, &value)?;
Ok(())
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this of all things makes me think of the slang thesis. in the larger scheme of things,
are you thinking that we will have something to represent components and a binding state?

from a being able to work with the "building blocks" of gfx -- being able to declare components based off of a prescribed set of interfaces (to start) and to compose them in entry points sounds ideal. definitely curious about your thoughts and insights here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Comments